src/main/java/org/scoula/domain/precontract/service/PreContractDataServiceImpl.java (1)

91-95: ownerMapper.selectIdentityId 단일 파라미터 호출 제거 및 2-파라미터 시그니처로 변경 필요

아직 ownerMapper.selectIdentityId(contractChatId) 형태의 단일 파라미터 호출이 남아 있습니다. 아래 위치들을 모두 두 파라미터(contractChatId, ownerId) 시그니처로 변경해 주세요:

• src/main/java/org/scoula/domain/precontract/service/PreContractDataServiceImpl.java:50
• src/main/java/org/scoula/domain/precontract/service/OwnerPreContractServiceImpl.java:138, 545
• src/main/java/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.java:41

매퍼 인터페이스 정의와 호출부 양쪽에서 모두 업데이트가 필요합니다.

src/main/java/org/scoula/global/config/ServletConfig.java (1)

98-113: 주석 처리된 CORS 설정: 유지/삭제 의사결정 필요 및 설정 중앙화 제안

현재 addCorsMappings 블록이 전부 주석 처리되어 있어 동작에 영향은 없습니다. WebSocket 쪽은 setAllowedOriginPatterns로 별도 관리 중인데, REST API CORS가 필요한 환경이라면 여기서 명시적으로 관리하거나, Nginx 단으로 일원화해 주석 코드를 제거하는 편이 깔끔합니다. 또한 허용 오리진 목록은 환경별로 빈번히 바뀌므로 application.yml 기반 프로퍼티로 중앙화하는 것을 권장합니다.

원칙: CORS를 Nginx에서 전담한다면 본 블록은 삭제하시고, Spring에서 관리한다면 주석을 해제해 실제 적용으로 전환해주세요. 어느 쪽으로 정리할지 확인 부탁드립니다.

src/main/java/org/scoula/global/websocket/config/WebSocketConfig.java (1)

49-57: 허용 오리진 패턴 관리 일원화 제안

STOMP 엔드포인트에 대한 setAllowedOriginPatterns 설정은 적절합니다. 다만 동일한 오리진 목록이 REST CORS(ServletConfig)와 분리되어 관리되면 누락/불일치가 발생하기 쉽습니다. 환경변수/프로퍼티(itzeep.cors.allowed-origins)로 중앙화하거나, 리버스 프록시(Nginx)에서 일원화하면 운영 편의성이 올라갑니다.

프록시(Nginx)에서 CORS를 전담하는 정책이라면 Spring 쪽 오리진 목록은 최소화하시겠습니까?

src/main/java/org/scoula/domain/chat/vo/ContractChat.java (2)

37-55: COMPLETE에서 getCurrentRound()가 1L을 반환 — 비라운드 상태를 null로 명확히 구분하는 것을 고려해 주세요.

현재는 ROUND가 아닌 모든 상태(포함: COMPLETE)에서 1L을 반환합니다. 이는 “라운드 맥락 없음”을 “1라운드”로 오인하게 만들 수 있습니다. 비라운드 상태는 null로 분리하는 편이 호출부에서 의도를 더 명확히 표현할 수 있습니다.

다음과 같이 완만한 리팩터를 제안드립니다(호출부의 null 처리 필요).

-      if (status == null) return 1L;
+      if (status == null) return null;
       switch (status) {
         case ROUND0:
           return 1L;
         case ROUND1:
           return 2L;
         case ROUND2:
           return 3L;
         case ROUND3:
           return 4L;
         case ROUND4:
           return 5L;
         default:
-          return 1L;
+          return null;
       }

참고:

• 만약 비즈니스 규칙상 COMPLETE를 “마지막 라운드로 간주”해야 한다면 default 대신 case COMPLETE:를 명시하고 적절한 값(예: 5L 또는 기대하는 라운드 인덱스)을 반환하도록 해 주세요.

---

21-21: 상태 판별 헬퍼 추가 제안: isComplete()

호출부 가독성과 중복 분기 제거를 위해 간단한 헬퍼를 두는 것을 권장합니다.

public boolean isComplete() {
    return status == ContractStatus.COMPLETE;
}

(필요하면 isFinalState() 등 도메인 용어에 맞춘 헬퍼도 함께 정리해 드릴 수 있습니다.)

src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml (1)

145-147: 계약별 본인인증 스코프 강화 OK — contract_step 추가 필터 권장

iv.contract_id = cc.contract_chat_id 조건 추가로 범위가 정확해졌습니다. 동일 사용자·다중 단계(START 외) 레코드가 존재할 수 있다면 contract_step='START'까지 함께 거는 것이 더 안전합니다.

적용 예시:

     WHERE cc.contract_chat_id = #{contractChatId}
-    AND iv.contract_id = cc.contract_chat_id
+    AND iv.contract_id = cc.contract_chat_id
+    AND iv.contract_step = 'START'

추가 제안:

• 성능을 위해 identity_verification(contract_id, user_id) 혹은 (user_id, contract_id, contract_step) 조합에 인덱스가 있는지도 확인 부탁드립니다.

src/main/java/org/scoula/domain/chat/service/ChatServiceImpl.java (1)

842-848: homeId 쿼리 파라미터 추가 좋습니다 — URI 빌더 사용으로 안전성/가독성 향상 권장

현재 문자열 연결은 동작하나, 쿼리 인코딩/구분자(?, &) 처리 리스크를 줄이기 위해 UriComponentsBuilder 사용을 권장합니다. 또한 BUYERURL은 경로와 쿼리를 혼합하고 있어 빌더로 명시적으로 분리하는 편이 안전합니다.

아래처럼 대체를 제안합니다:

-String contractChatUrl =
-        URL
-                + PRECONTRACTURL
-                + (contractChatRoomId.toString())
-                + BUYERURL
-                + "&homeId="
-                + (originalChatRoom.getHomeId());
+String contractChatUrl = UriComponentsBuilder.fromHttpUrl(URL)
+        .path(PRECONTRACTURL)
+        .path(contractChatRoomId.toString())
+        .path("/buyer")
+        .queryParam("step", 1)
+        .queryParam("homeId", originalChatRoom.getHomeId())
+        .build()
+        .toUriString();

추가 필요 import (파일 상단):

import org.springframework.web.util.UriComponentsBuilder;

유의:

• originalChatRoom.getHomeId()가 null일 가능성이 있다면, 쿼리 파라미터 추가 전 null 가드가 필요합니다.

src/main/java/org/scoula/domain/chat/service/ContractChatServiceInterface.java (2)

308-310: Map 반환 대신 명시적 DTO 도입 고려

acceptFinalContract(...)가 Map<String, Object>를 반환하면 타입 안정성이 떨어집니다. 응답 스키마가 고정적이라면 DTO를 정의해 교체하는 것을 권장합니다. 예: FinalContractAcceptResultDto { status, contractChatId, nextStep, ... }

---

305-307: requestFinalContract vs requestFinalContractConfirmation – Javadoc로 역할 분리 필요

현재 두 메서드 모두 동일한 Javadoc(임대인이 최종 특약 확정 요청)을 사용해 개념이 혼동됩니다.
각 메서드가 담당하는 워크플로우(예: 계약서 생성 요청 vs. 확정 요청), 상태 전이 트리거(COMPLETE 포함 여부) 등을 Javadoc에 분리·명시해 주세요.
구현체인 ContractChatServiceImpl에는 이미 두 메서드가 모두 정의·구현되어 있으니, 동시 갱신 여부는 추가 조치 없이도 보장됩니다.

수정 대상:

• src/main/java/org/scoula/domain/chat/service/ContractChatServiceInterface.java
  • requestFinalContract(...) Javadoc – 신규 메서드 역할(특약서 생성/전송 등) 구체화
  • requestFinalContractConfirmation(...) Javadoc – “확정 요청” 워크플로우 구분

src/main/java/org/scoula/domain/chat/controller/ContractChatControllerImpl.java (1)

306-326: 디버그 로깅 레벨 하향 권장

payload/principal/스레드명 등 상세 정보는 INFO보다 DEBUG가 적절합니다. 운영 로그 노이즈와 민감 정보 노출 위험을 줄이기 위해 레벨 조정 권장합니다.

-            log.info("=== WebSocket 계약 채팅방 입장 시작 ===");
-            log.info("payload: {}", payload);
-            log.info("principal: {}", principal != null ? principal.getName() : "null");
-            log.info("Thread: {}", Thread.currentThread().getName());
+            log.debug("=== WebSocket 계약 채팅방 입장 시작 ===");
+            log.debug("payload: {}", payload);
+            log.debug("principal: {}", principal != null ? principal.getName() : "null");
+            log.debug("Thread: {}", Thread.currentThread().getName());

-            log.info("추출된 userId: {}, contractChatId: {}", userId, contractChatId);
+            log.debug("추출된 userId: {}, contractChatId: {}", userId, contractChatId);

-            log.info("=== WebSocket 계약 채팅방 입장 완료 ===");
+            log.debug("=== WebSocket 계약 채팅방 입장 완료 ===");

src/main/java/org/scoula/domain/contract/dto/LegalityDTO.java (1)

20-22: 상위 스키마 확장(data/error/timestamp) — success/message 중복 노출 가능성 정리 권장

LegalityDTO 상위 레벨에 success, message와 data/error/timestamp가 공존하면, 외부 응답을 ApiResponse<LegalityDTO>로 감쌀 때 중첩·중복 필드로 혼란이 생길 수 있습니다. 한 가지 패턴으로 정리하는 것을 권장합니다.

• 옵션 A: LegalityDTO는 순수 Payload 컨테이너(data/error/timestamp만)로 유지
• 옵션 B: LegalityDTO 단독 응답이라면 success/message 유지, data를 평탄화

외부 영향이 적다면, 아래처럼 단일 패턴으로 정리해 보세요(참고용):

// 제안: success/message 제거하고 Payload 중심 유지
// 또는 @Deprecated로 마이그레이션 단계 표시

Swagger/문서 스키마도 함께 업데이트 해 주세요.

src/main/java/org/scoula/domain/precontract/service/OwnerPreContractServiceImpl.java (1)

443-446: saveContractMongo 호출 위치 및 예외 처리 보강 제안

검증 결과 ContractService.saveContractMongo(Long, Long) 시그니처는 문제없이 일치합니다.
하지만 URL 링크 전송(chatService.handleChatMessage) 이후 Mongo 저장 실패 시 사용자에게 이미 링크가 발송된 상태가 되어 흐름이 어색해질 수 있으니, 예외 처리를 보강하길 권장드립니다.

• 대상 위치

  • 파일: src/main/java/org/scoula/domain/precontract/service/OwnerPreContractServiceImpl.java
    • 라인 443: contractService.saveContractMongo(contractChatId, userId);

• 제안된 변경 (try-catch 추가)

-          contractService.saveContractMongo(contractChatId, userId);
+          try {
+              contractService.saveContractMongo(contractChatId, userId);
+          } catch (Exception e) {
+              log.error("계약 Mongo 저장 실패 - contractChatId: {}, userId: {}", contractChatId, userId, e);
+              throw new BusinessException(OwnerPreContractErrorCode.OWNER_INSERT, "계약 데이터 저장 실패", e);
+          }

또한 RDB 중심의 @Transactional 범위에 MongoTemplate 작업이 포함되지 않으므로, 강한 일관성이 필요하다면 outbox/event 기반 비동기 처리나 분산 트랜잭션 대안을 검토해 주세요.

src/main/resources/org/scoula/domain/precontract/mapper/TenantPreContractMapper.xml (2)

30-37: selectIdentityId: 불필요 조인 제거 또는 범위 제약 추가 권장

현재 쿼리는 contract_chat(cc)과 identity_verification(iv)를 조인하지만, cc에 대해 contract_chat_id 필터가 없어 실질적으로는 iv.contract_id 조건만으로 동작합니다. 선택지는 두 가지입니다.

• 단순화(권장): cc 조인을 제거하고 iv만 조회
• 보강: cc.contract_chat_id = #{contractChatId} 조건을 추가해 명시적 범위 제약

단순화 예시는 아래와 같습니다.

-        SELECT DISTINCT iv.identity_id
-        FROM contract_chat cc
-                 INNER JOIN identity_verification iv
-                            ON cc.buyer_id = iv.user_id
-        WHERE cc.buyer_id = #{userId}
-        AND iv.contract_id = #{contractChatId}
+        SELECT iv.identity_id
+        FROM identity_verification iv
+        WHERE iv.user_id = #{userId}
+          AND iv.contract_id = #{contractChatId}

---

262-268: 중복 기능 제거: selectRentTypeAll는 기존 selectRentType와 목적이 겹칩니다

이미 상단의 selectRentType가 contractChatId와 userId를 기준으로 lease_type을 반환합니다. selectRentTypeAll은 실질적으로 동일 목적(심지어 본 XML에서는 userId 미사용)이어서 API 표면적을 늘리고 혼동을 유발합니다. 본 메서드는 제거하고 기존 selectRentType를 재사용하는 방향을 권장합니다.

아래처럼 제거해 주세요.

-  <select id="selectRentTypeAll" resultType="string">
-    select h.lease_type
-    FROM contract_chat cc
-           INNER JOIN home h
-                      ON cc.home_id = h.home_id
-    WHERE cc.contract_chat_id = #{contractChatId}
-  </select>

원하시면 관련 Java 인터페이스와 호출부에서도 제거 패치를 도와드리겠습니다.

src/main/java/org/scoula/domain/contract/repository/ContractMongoRepository.java (1)

106-122: System.out.println 대신 로거 사용 및 일관된 로깅 체계로 교체 제안

Repository 클래스에서 표준 출력 사용은 운영 로그 수집/레벨 제어에 불리합니다. 프로젝트 전반의 @log4j2 사용에 맞춰 교체를 권장합니다.

변경 예시:

-          System.out.println("특약 내용 삭제 완료 - contractChatId: " + contractChatId);
+          log.info("특약 내용 삭제 완료 - contractChatId: {}", contractChatId);

추가로, 클래스에 로거 주입이 필요합니다(파일 상단 변경):

+import lombok.extern.log4j.Log4j2;
@@
-@Repository
+@Repository
+@Log4j2
 public class ContractMongoRepository {

src/main/java/org/scoula/domain/precontract/mapper/TenantPreContractMapper.java (1)

42-44: 중복 메서드 정리: selectRentTypeAll 제거를 권장

동일한 반환(lease_type)을 제공하는 selectRentType가 이미 존재합니다. selectRentTypeAll은 불필요한 중복으로 보이며 XML에도 신규 쿼리가 추가되었습니다. API 표면 축소를 위해 메서드/매퍼를 제거하고 기존 selectRentType만 유지하는 것을 권장합니다.

제거 예시:

-      Optional<String> selectRentTypeAll(
-              @Param("contractChatId") Long contractChatId, @Param("userId") Long userid);

XML의 해당 매퍼 블록도 함께 삭제해 주세요(별도 코멘트에 패치 예시 포함).

src/main/java/org/scoula/domain/contract/service/ContractFixServiceInterface.java (2)

5-10: 서비스 인터페이스 추가는 패턴에 부합합니다

서비스가 Interface/Impl 패턴을 따르도록 분리된 점 좋습니다. 이후 구현체 네이밍만 컨벤션에 맞추면 더 깔끔해질 것 같습니다.

---

7-7: 서비스 메서드 반환 타입은 void 권장 (Void 지양)

Void 박싱 타입은 항상 null을 반환해야 하므로 불필요한 널 처리/오해 소지가 있습니다. 부수효과만 있는 서비스 저장 메서드는 void가 적합합니다.

적용 diff:

-      Void saveSpecialContract(Long contractChatId, Long userId);
+      void saveSpecialContract(Long contractChatId, Long userId);

src/main/java/org/scoula/domain/contract/controller/ContractController.java (1)

122-130: accept 응답을 Map 대신 명시적 DTO로 반환하세요

Map은 스키마가 불분명해 API 문서화/호환성 유지가 어려워집니다. 명시적 DTO로 교체를 권장합니다. 또한 본문 유효성 검증을 위해 @Valid 추가를 검토해주세요.

예시 diff (시그니처 교체):

-      @ApiOperation(value = "최종 계약서 확정 수락 (임차인)", notes = "임차인이 임대인의 최종 특약서 확정 요청을 수락합니다.")
-      ResponseEntity<ApiResponse<Map<String, Object>>> acceptFinalContract(
-              @PathVariable Long contractChatId,
-              @RequestBody FinalContractDeletionResponseDto responseDto,
-              Authentication authentication);
+      @ApiOperation(value = "최종 계약서 확정 수락 (임차인)", notes = "임차인이 임대인의 최종 특약서 확정 요청을 수락합니다.")
+      ResponseEntity<ApiResponse<FinalContractAcceptResultDto>> acceptFinalContract(
+              @PathVariable Long contractChatId,
+              @Valid @RequestBody FinalContractDecisionRequestDto request,
+              Authentication authentication);

추가로 필요한 DTO 예시(별도 파일):

// FinalContractDecisionRequestDto.java
public class FinalContractDecisionRequestDto {
  @NotNull
  private Boolean accepted;
  // getter/setter
}

// FinalContractAcceptResultDto.java
public class FinalContractAcceptResultDto {
  private Long contractChatId;
  private String status; // e.g., "COMPLETE"
  private String message;
  // getter/setter, builder
}

src/main/java/org/scoula/domain/contract/service/ContractFixService.java (2)

24-27: 구현체 클래스명 컨벤션 미준수: ContractFixServiceImpl로 변경 권장

레포 컨벤션(Interface/Impl)에 맞추려면 구현체를 ContractFixServiceImpl로 이름짓는 것을 권장합니다. 빈 주입은 타입 기반이라 기능 영향은 없으나, 팀 컨벤션 일관성을 위해 정리해두면 좋습니다.

적용 diff:

-@Service
-@RequiredArgsConstructor
-@Log4j2
-public class ContractFixService implements ContractFixServiceInterface {
+@Service
+@RequiredArgsConstructor
+@Log4j2
+public class ContractFixServiceImpl implements ContractFixServiceInterface {

(파일명 및 기타 참조도 함께 변경 필요)

---

124-162: 검증 헬퍼의 접근 제한자 및 책임 범위 조정 제안

validateUserId, validateIsOwner는 외부에 노출할 필요가 없어 보입니다. 공개 범위를 private으로 줄여 외부 오용을 방지하고, 역할을 명확히 하세요.

적용 diff:

-      public void validateUserId(Long contractChatId, Long userId) {
+      private void validateUserId(Long contractChatId, Long userId) {
...
-      public void validateIsOwner(Long contractChatId, Long userId) {
+      private void validateIsOwner(Long contractChatId, Long userId) {

추가로, RestTemplate 타임아웃 설정(커넥션/소켓)과 ObjectMapper 빈 재사용을 도입하면 장애시 대기 현상 완화와 성능/메모리 사용 개선에 도움이 됩니다.

src/main/java/org/scoula/domain/contract/controller/ContractControllerImpl.java (1)

213-230: 최종 확정 ‘요청’ 엔드포인트: 권한(임대인) 검증이 서비스에서 수행되는지 확인 필요

컨트롤러 단에서는 인증만 확인하고 있어, 임대인만 호출 가능하도록 서비스 레이어에서 역할 검증이 수행되는지 확인 부탁드립니다. 없다면 추가하세요.

또한 예외 응답의 일관성을 위해 ApiResponse.error에 에러 코드/메시지 포맷을 통일하는 것도 고려해 주세요.

src/main/java/org/scoula/domain/contract/service/ContractServiceImpl.java (8)

7-7: @lazy 주입 도입 — 순환참조 해소 목적이면 OK, 아니라면 지양 권장

contractChatService에 @lazy를 적용해 순환참조를 회피한 것으로 보입니다. 실제 순환 구조가 없는데 초기화 지연만으로 문제를 덮으면 런타임에 늦게 드러나는 실패를 초래할 수 있습니다. 꼭 필요한 경우에만 유지하세요.

필요 시 순환 의존 경로를 알려주시면 구조적 개선(포트/어댑터로 분리, 이벤트 발행 등) 제안드리겠습니다.

Also applies to: 42-42

---

166-173: 문자열 상수는 private static final로 승격 권장

step3StartMessage는 불변/공유되는 상수입니다. 가시성 및 불변성 보장을 위해 static final로 선언하고 UPPER_SNAKE_CASE 네이밍을 권장합니다.

-    String step3StartMessage = "다음은 3단계: ‘특약 조율' 단계입니다.\n"
+    private static final String STEP3_START_MESSAGE = "다음은 3단계: ‘특약 조율' 단계입니다.\n"

그리고 사용처를 STEP3_START_MESSAGE로 교체하세요.

---

185-211: 중복 스텝 업데이트 및 Thread.sleep 사용은 제거/비동기화 권장

• nextSteps(...)가 이미 두 사용자 수락 시 STEP1로 변경하는데 여기서 다시 STEP1로 업데이트하고 있습니다. 중복/경합 가능성이 있으며 불필요한 DB write입니다.
• Thread.sleep으로 서비스 스레드를 블로킹하면 서버 처리량에 악영향을 줍니다. 메시지 지연 연출은 큐/스케줄러/프론트 타이머로 처리하는 게 안전합니다.

중복 업데이트 제거 예시:

-          // 스텝 변경
-          contractChatMapper.updateStatus(contractChatId, ContractChat.ContractStatus.STEP1);

지연은 @async, 이벤트 발행, 혹은 메시지 브로커/프론트 타이머로 대체를 권장합니다.

---

234-241: 전/월세 타입 매핑 견고성 개선

rentType 문자열 비교는 NPE와 대소문자 이슈에 취약합니다. Enum 사용 또는 equalsIgnoreCase로 보완하세요.

-          String rentTypeKr;
-          if(rentType.equals("JEONSE")){
-              rentTypeKr = "전세";
-          }else{
-              rentTypeKr="월세";
-          }
+          String rentTypeKr = "월세";
+          if ("JEONSE".equalsIgnoreCase(rentType)) {
+              rentTypeKr = "전세";
+          }

---

257-257: Thread.sleep(2000)로 서비스 블로킹 — 비동기/프론트 타이머로 대체 권장

서버 스레드 블로킹은 처리량 저하/타임아웃을 유발합니다. 메시지 간 딜레이는 클라이언트 타이머 또는 비동기 작업으로 연출하세요.

원하시면 @async 기반 또는 이벤트 발행 방식으로 변환 패치를 제안드리겠습니다.

---

278-309: Redis 저장 포맷/TTL/경합 처리 보완 필요

• 단일 문자열 "deposit,monthly" 포맷은 확장/검증이 약합니다. Hash 또는 JSON 저장을 고려하세요.
• TTL 미설정으로 스테일 데이터가 남을 수 있습니다.
• 동일 키에 대한 동시 업데이트 경쟁을 고려해 setIfAbsent 또는 Lua 스크립트/분산락이 필요할 수 있습니다.

간단 개선 예시(TTL 추가):

-        stringRedisTemplate.opsForValue().set(redisKey, paymentValue);
+        stringRedisTemplate.opsForValue().set(redisKey, paymentValue, java.time.Duration.ofHours(6));

향후 확장을 고려해 opsForHash().putAll(...) 구조로 전환을 권장합니다.

---

640-669: formatWonShort 축약 규칙 명확화 및 long 시그니처 권장

• 금액이 1만 미만일 때 7,500 → "7천원"으로 내림 처리됩니다. 요구사항이 반올림/표시 정밀도를 어떻게 요구하는지 명확화 필요.
• 음수 금액, 매우 큰 금액(억 단위 초과 수십억) 케이스에 대한 명세/테스트가 있으면 좋습니다.
• long 시그니처로 변경해 오버플로우 여지를 제거하세요.

원하시면 경계값 테스트(JUnit)와 함께 long 기반 구현으로 일괄 수정 PR 패치 드리겠습니다.

---

331-391: 금액 필드 타입 long으로 변경 검토

현 PaymentDTO, ContractDTO, ContractMongoDocument, AIMessageDTO 등에서 depositPrice/monthlyRent를 int로 선언하고 있어
2,147,483,647원을 초과하는 금액이 들어올 경우 오버플로우가 발생할 수 있습니다. 아래 항목을 검토해주세요:

• src/main/java/org/scoula/domain/contract/dto/PaymentDTO.java,
  ContractDTO.java, ContractMongoDocument.java, AIMessageDTO.java 등 관련 DTO·문서 클래스의 필드 타입을 int → long으로 변경
• repository.updateDepositPrice(...) 메서드 시그니처 및 호출부 수정
• formatWonShort(long) 오버로드 또는 구현 검토
• 변경에 따른 MongoDB 스키마, API 응답 스펙, 연관 VO/DTO/엔티티 영향 범위 확인

파싱 부분 예시:

-    int depositPrice = Integer.parseInt(amounts[0]);
-    int monthlyRent   = Integer.parseInt(amounts[1]);
+    long depositPrice = Long.parseLong(amounts[0]);
+    long monthlyRent  = Long.parseLong(amounts[1]);

광범위한 타입 변경이 필요하므로 영향 범위를 면밀히 검토하시기 바랍니다.

src/main/java/org/scoula/domain/chat/service/ContractChatServiceImpl.java (5)

497-513: REDIS 기반 입장 처리 및 PRESENCE 브로드캐스트 — 타당

방 멤버십을 Set으로 관리하고 역참조 키를 저장하는 구조는 명료합니다. 단, 비정상 종료로 leave가 호출되지 않는 경우를 대비해 userCurrentRoomKey에 짧은 TTL을 두는 것도 고려하세요.

- stringRedisTemplate.opsForValue().set(userCurrentRoomKey(userId), contractChatId.toString());
+ stringRedisTemplate.opsForValue().set(userCurrentRoomKey(userId), contractChatId.toString(), java.time.Duration.ofHours(4));

---

519-526: 온라인 상태의 이중 소스(REDIS + in-memory Map) 혼용 — 단일 소스로 일원화 권장

현재 isUserInContractChatRoom은 REDIS를, setContractChatUserOffline은 in-memory Map을 갱신합니다. 혼용 시 일관성 문제가 생깁니다. 온라인 상태 관리는 REDIS 단일 소스로 통일하고 in-memory Map 관련 메서드/필드를 제거하는 것이 깔끔합니다.

Also applies to: 629-638, 642-648

---

531-572: 디버그 로그 과다 — 운영 환경에서의 노이즈 최소화

현 시점의 상세 로그는 개발에 유용하나 운영에서는 과다합니다. log.isDebugEnabled() 가드 또는 로그 레벨 조정으로 노이즈를 줄이세요.

- log.info("=== getContractChatOnlineStatus(REDIS) 시작 ===");
+ log.debug("=== getContractChatOnlineStatus(REDIS) 시작 ===");

---

2478-2614: 트랜잭션 내 장시간 I/O와 Thread.sleep — 비동기화/워크플로우 분리 권장

acceptFinalContractConfirmation(...)에서

• Mongo/Redis 업데이트 트랜잭션 범위 내에 Thread.sleep과 외부 AI 호출(법적 검토)이 포함돼 있습니다.

• 이는 트랜잭션 지연/락 홀드/서버 스레드 고갈/타임아웃 리스크를 키웁니다.

• 데이터 상태 변경(DB/Redis)은 빠르게 끝내고 커밋.

• 법적 검토는 @async 또는 이벤트 발행(예: Spring 이벤트/메시지 브로커)로 비동기 실행.

• 중간 메시지는 SSE/WebSocket으로 스트리밍하되 서버 스레드 블로킹은 피하세요(딜레이 연출은 클라이언트 타이머로).

---

107-126: 오프라인 시 메시지 전송 정책 UX/요건 재확인 필요

• 현재 오프라인 상대에게 메시지를 저장하지 않고 전송을 차단한 뒤 에러만 반환하는 로직은 비동기 채팅/알림(FCM/SSE 등) 시나리오와 상충할 수 있습니다.
• 일반적으로는 메시지를 DB에 저장하고, 오프라인 사용자에게 푸시 또는 알림을 발송하는 방식을 사용합니다.

제안:

• 메시지를 항상 저장
• 상대가 오프라인일 경우 NotificationServiceImpl.createChatNotification(...) 호출을 통해 푸시 알림 발송
• 송신자에게는 에러 대신 “상대가 현재 오프라인입니다. 읽으면 알림 드릴게요.” 안내 메시지를 별도 채널로 전송

※ STOMP 설정(WebSocketConfig)에서 config.setUserDestinationPrefix("/user")가 적용되어 있어,
convertAndSendToUser(dto.getSenderId().toString(), "/queue/contract/error") 호출 방식과 정합성이 확인되었습니다.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: Whatdoyumin
PR: ITZEEP/backend#40
File: src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml:188-192
Timestamp: 2025-08-04T00:51:44.587Z
Learning: In the ITZEEP backend codebase, the owner_precontract_check table uses contract_chat_id as both primary key (PK) and foreign key (FK), so selectOwnerPrecheckId correctly returns contract_chat_id for use in upsertRestoreScope operations. This is confirmed by the join pattern "LEFT JOIN owner_restore_scope ors ON opc.contract_chat_id = ors.owner_precheck_id" in the mapper files.

Learnt from: Whatdoyumin
PR: ITZEEP/backend#40
File: src/main/resources/org/scoula/domain/precontract/mapper/OwnerPreContractMapper.xml:188-192
Timestamp: 2025-08-04T00:51:44.587Z
Learning: In the ITZEEP backend codebase, the owner_precontract_check table uses contract_chat_id as both primary key (PK) and foreign key (FK), so selectOwnerPrecheckId correctly returns contract_chat_id for use in upsertRestoreScope operations.

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/domain/*/repository/*Repository.java : Place MongoDB repositories under `src/main/java/org/scoula/domain/*/repository/*Repository.java`

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/**/service/*Service{Interface,Impl}.java : Use interface-implementation pattern for services: `*ServiceInterface.java` (interface) and `*ServiceImpl.java` (implementation)

Learnt from: CR
PR: ITZEEP/backend#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-12T03:59:30.512Z
Learning: Applies to src/main/java/org/scoula/**/controller/*Controller{,Impl}.java : Use interface-implementation pattern for controllers: `*Controller.java` (interface) and `*ControllerImpl.java` (implementation)